The field of the invention is medical imaging systems and more specifically start-up protocols for medical imaging system workstations.
Herein, while it is recognized that physicians often work through radiologists to generate images using imaging systems, to simplify this explanation each unique radiologist/physician pair (i.e., a unique combination of a radiologist and a physician) will be referred to generically as a “physician”. In addition, while the invention may be used with any complex medical imaging system, the invention will be described in the context of a magnetic resonance imaging (MRI) system.
Medical imaging systems have been used for many years to generate diagnostic quality medical images of various types. Exemplary early imaging systems often were only capable of generating images having very similar characteristics (i.e., all images generated by a specific imaging system tended to have similar or identical image quality characteristics, be of the same view, etc.). This was because early imaging systems were relatively simple having only a small number of settable data acquisition and data processing parameters.
Over time data collecting hardware, processing power and software applications have been developed that facilitate extremely complex imaging systems having many different applications. In complex systems often a workstation is provided that runs all of the applications. An exemplary workstation often includes a graphical user interface (GUI), one or more input devices (e.g., a mouse, a keypad, etc.) and either a local or a remotely linked server that runs the applications and controls the imaging system.
In a nuclear magnetic resonance imaging (MRI) system applications include a plurality of image viewer applications, a plurality of data acquisition applications, a plurality of separate data manipulation applications, various data filtering applications, patient data applications (i.e., enabling input and modification of patient information), database browser applications, etc. While a complex imaging system may include a huge number of applications, in order to simplify this explanation it will be assumed that an exemplary imaging system includes 20 applications.
While each complex imaging system may include a huge number of applications, each physician may only require a small sub-set of available applications to perform a typical imaging process. Thus, in the exemplary 20 application system described herein, it will be assumed that a first physician may only require a first sub-set of 7 applications, a second physician requires a second sub-set of 10 applications where the second subset includes 4 of the applications in the first subset and 6 other applications that are not in the first subset, a third physician requires a third application subset including two applications from the first subset and one application that is in neither the first or second subset and so on.
In addition to the plethora of applications that some systems may include, many applications have adjustable parameters that either affect operation of the workstation or final image characteristics. For instance the industry has developed many different filtering kernels for filtering acquired data in different ways to reduce image aliasing to different degrees. Filtering is often computationally intensive and therefore more complex filtering techniques can take an appreciable amount of time to complete.
The degree of acceptable alliasing in an image depends at least in part on what a physician wants to accomplish during an imaging session. Thus, in some cases where general shape of an anatomical object is to be observed a relatively large degree of alliasing may be acceptable whereas in other cases where intricate details of an object have to be observed only a small degree of alliasing may be acceptable.
In almost all imaging sessions processing speed is extremely important to increase system throughput (i.e., the number of imaging sessions that occur in a day), to increase patient comfort and to reduce physician time necessary for imaging and analysis. Thus, whenever possible, imaging protocols that expedite data acquisition and expedite processing and viewing while still rendering images that are suitable for their intended use should be selected. This means that different physicians attempting to accomplish different goals via the imaging system will routinely select different filtering techniques to maximize throughput and while minimizing alliasing.
As another example of physicians selecting different applications, different physicians wanting to examine the same anatomical portion of a patient will often require different image sequences. For instance, a first physician may routinely want to view seven different images sequenced in a specific order for “click-through” viewing via a GUI while a second physician may only want three images sequenced in a different fashion to diagnose the same ailment.
As yet another example, in an MRI system there are many different data acquisition pulse sequences that can be generated that cause different anatomical tissues to be highlighted. Again, different physicians often find different highlighting techniques to be advantageous and therefore the different physicians often require selection of varying pulse sequences.
One other example includes setting preferences related to other physicians that are granted access to images generated by a particular physician. For example, where ten physicians each use a system, one of the ten may want to by default, grant access to images generated by the physician to three of the other physicians. These preferences are currently set each time a physician accesses the system.
Hereinafter preferred applications and preferred preferences are collectively referred to as preferred applications unless indicated otherwise.
In many radiology departments, throughout the course of a day many physicians will use an imaging system. To use an imaging system a physician typically schedules an imaging session and, at the scheduled time, accesses the system workstation and sets up application programming parameters for a specific imaging session. Depending on physician control, all or any subset of the applications may be employed during the imaging session. To this end, despite their operation behind the scenes, often the separate applications are transparent to the physician. Thus, the physician may perform a function that causes three or four or more applications to operate in parallel or in a sequence behind the scenes. At the end of the session the physician may clear all application parameter settings.
During the next imaging session another physician steps through the process described above in a similar fashion, the applications and their orders perhaps differing between the first and second sessions based on physician preferences.
During any imaging session the physician controlling the session is unknown to the system and therefore the system cannot independently determine which of the 20 applications and which application parameters the physician prefers and requires. For instance, during the first imaging session the system cannot determine if the physician is the first, second or third physician described above. Instead, the system simply waits for the physician to specify his preferences.
In order to have all applications ready for use by whichever physician uses the system, upon startup (i.e., when the system is first booted up in the morning), exemplary imaging systems typically boot all system applications. For instance, in the present example, upon startup all 20 applications are booted. In this manner, when a physician accesses the system at the beginning of any subsequent imaging session, no matter which subset of the 20 applications the physician intends to employ, the applications have already been booted up and are ready for use. Thus, the physician can simply begin setting application parameters and then run the preferred applications.
While systems like the one described above facilitate rapid application employment after the initial startup process, such systems have several shortcomings. First, because all applications are booted upon initial startup, the startup process duration is relatively long and therefore can delay the first imaging session.
Second, booting up all applications and maintaining all of the applications in a supported state has adverse affects on system performance. To this end, while a subset of applications may all be performable to support an imaging function, sometimes a reduced set of functions may be able to perform essentially the same function but with slightly different results. For instance, while each of 10 applications may be applicable to a specific function, some physicians may require only 5 of the applications to obtain an image for the intended purpose. In this case, while an automated system may use all 10 applications, performance could be enhanced by using only the preferred 5 applications.
Increasing the number of simultaneously running applications increases the time required to complete an application cycle for any one of the applications being performed. Thus, where 10 applications are booted and are performed during an imaging session the session duration will typically be longer than the session duration where only 5 applications are performed.
Even where applications are not in current use and therefore do not affect data processing speed, the fact that the applications are booted up means that they reside on a system memory. Such application storage itself reduces system performance as additional data swapping is required to manage collected data during processing.
Moreover, in cases where several applications run in parallel, it may be that only a subset of the running applications is critical while others of the running applications are not critical. For instance, during data acquisition, it is advantageous if the data acquisition applications remain fully supported so that all potential data is collected while other applications such as processing of the raw data can be performed, if necessary, at a later time. If acquisition applications are not fully supported the result may be to prolong the data acquisition process. As indicated above, in all imaging processes patient comfort is increased and potential movement is minimized by reducing acquisition process duration and therefore process duration should be minimized whenever possible.
Third, even though user preferred applications are booted prior to a physician accessing the system and thus are ready to go upon access, preferred preferences still have to be separately set for each physician. This process is time consuming and reduces system throughput.
To ensure support for critical applications when a processor becomes bogged down, some systems are programmed to suspend or shut down non-critical applications so that the critical applications can remain fully supported. For instance, during data acquisition, when a processor reaches a threshold central processor unit (CPU) saturation (e.g., 75%), the processor turns off non-critical applications so that critical applications remain fully supported. While this “load thresholding” feature is advantageous, this feature is typically programmed into the system and, as with the applications that are booted, cannot be modified (i.e., criticality cannot be modified, % threshold cannot be modified, etc.) to support separate preferences of each physician.